1. Field of the Invention
The present invention relates to an improved data processing system and, in particular, to a method and apparatus for multicomputer data transferring. Still more particularly, the present invention provides a method and apparatus for computer-to-computer session management.
2. Description of Related Art
Information technology (IT) systems and the Internet have fueled commercial activity. While IT systems have significant benefits, at the same time they pose potential security threats from unauthorized third parties. Indeed, the lack of security in modern IT systems has emerged as a threat to the integrity of global computer networks.
To deal with this problem, IT systems provide a number of known services: data authentication, data confidentiality, entity authentication, and entity authorization. Data authentication typically consists of two sub-services: data integrity and data origin authentication. A data integrity service is used to convince a receiver of some item of given data that the data was not changed during transit, and data origin authentication proves to the receiver the identity of the real sender. Data confidentiality protects against disclosure of data during transmission. Entity authentication provides a system with proof that a certain entity is who they claim to be.
Authorization is the act of determining whether an authenticated entity has the right to execute an action. Authorization and authentication thus are dual services. To be able to provide authorization, it is necessary to determine who the entity is, e.g., by entity authentication. Authorization, in general, consists of two separate stages: the provision of privileges to a particular entity, e.g., authorization credentials, and the use of these privileges by the receiving entity in combination with access decision rules at a protected service or a protected resource to determine if access should be granted to the entity.
The client-side applications of many IT systems are now based on a Web browser application architecture because of its adaptability to multiple uses. Through the standard Hypertext Transfer Protocol (HTTP), a user of a browser application on a client machine can gain access to resources or services on any HTTP-enabled server. If the user at the client desires to access a protected resource or a protected service at the server that can only be accessed by an authenticated and authorized user, however, there must be some process to authenticate and authorize the user/client.
As is well-known, a cookie is a data item that is stored on a client by a server through a particular user's web browser. When a user of a client machine visits a Web server, the server may return a cookie to the user's browser to be stored in a client-side cookie cache. When a cookie is “set”, i.e. stored, as part of an HTTP transaction, it may include the path, i.e. domain, for which the cookie is valid, the cookie's name and value, and other optional attributes, such as the cookie's expiration date. In most cases, the client browser automatically stores the cookie data by default, sometimes without giving the user the option or the knowledge of it being done. When the user revisits the server at some later point in time, the cookie is sent with the request, thereby identifying the user to the server.
A typical cookie can be quite convenient for identifying a user or client to a server, but depending on the type of resources and services provided by a server, a cookie introduces security vulnerabilities into client-server communications. In some prior art solutions, identification data is forwarded within a cookie when the client browser issues a request for a protected resource to the server that set the cookie. Such an approach can be insecure because an attacker that obtains possession of the cookie might be able to gain user authorization to access the protected resource. In other words, an insecure implementation of a cookie might equate proof of possession with proof of identity. In fact, some servers equate possession of a cookie with authentication of the identity of the client/user that possesses the cookie, thereby relying on the cookie as a short-cut for identifying a user or client by other means even though cookies may be stolen and then used maliciously. More insidiously, some cookie implementations also contain the username and password required by a user to authenticate into a system. This is particularly dangerous because if this information is stolen, a malicious user can authenticate to a system using other means, such as a login application, and thereby appear to be the user that is being impersonated. The malicious user could thereafter have his own cookies set by the server at the malicious user's client machine.
Cookies can be either persistent cookies, which are stored on disk, or memory cookies, which are stored in memory. Persistent cookies reside in a client file or cookie cache, such as “cookies.txt”, after the client browser is closed and are available during the next browser session. Memory cookies disappear when the browser is shut down. However, both types of cookies can be dangerous since both types of cookies can be stolen by malicious code, such as a JavaScript that has a Trojan horse, i.e. benign code that hides malicious code, through interception of network traffic, or by a malicious server in the cookie's intended domain of use. Although both types of cookies are vulnerable to theft, persistent cookies are a bigger threat because they can be stolen from the cookie file. As a consequence, these prior art schemes are highly susceptible to replay attacks wherein one who acquires a cookie can simply assert it to gain access to a protected resource or protected service.
As mentioned above, applications in many IT systems are increasingly using Web-based or Internet-based standards, such as HTTP. However, HTTP is a stateless protocol—each client request to a server establishes a connection between the client and the server, but according to a strict interpretation of the HTTP standard, the connection is considered closed when the server responds to the client request. The client may immediately generate another request to the server, but the subsequent request is considered to establish another connection. Obviously, the most common interactions between a client and a server require multiple requests that are related to each other and that the server needs to know are related to one another. In other words, the server needs to maintain a session context for each client through which it determines that a request from a client is related to a previous request and requires a response based on this temporal relationship. Hence, most servers need a session management mechanism.
Due to the round-trip nature of a cookie being issued from a server to a user or client and then being returned to the server at a later point in time, cookies provide a degree of state to HTTP. Therefore, cookies are frequently used for session management purposes within the server that issued the cookie.
Although session management within the server is facilitated or enabled by the use of cookies, the use of cookies for secure session management has been historically problematic because of the client-side vulnerabilities that were discussed above with respect to authentication. Since cookies are supported by all commercial Web browsers and servers, cookies are frequently used for detailed session management, such as tracking user movement within Web sites. From a security standpoint, however, a computational environment that employs cookies to enable secure access to protected resources and/or services while storing cookies in cookie caches creates vulnerabilities that are exploitable via the acquisition of cookies by malicious persons.
Other alternative security methodologies rely heavily on client-side functionality, but most suffer from the fundamentally uncontrolled nature of most client-based systems. The infrastructure required to support these client systems and to maintain a secure trust chain among their components is considered to be unwieldy in many environments.
Therefore, it would be advantageous to have a lightweight security solution for ongoing session management in a Web environment. It would be particularly advantageous to have a method and system for cookie-based secure session management that is server-based and is compliant with existing Internet protocols.